Stop the asset page's KPIs counting a day the chart does not show - #2434

Context:
- The KPI day-counting fix was split out into PR #2434, since it changes
  user-visible numbers while this PR is a performance change. Both
  branches carry the same code change and merge cleanly either way, but
  the changelog would have gained the line twice.

Change:
- Drop the entry here. The date-corruption entry stays, as that fix is
  needed by the cache in this PR.

Signed-off-by: F.N. Claessen <felix@seita.nl>

Context:
- Review feedback: the entry linked both the PR and the issue it closes.

Change:
- Drop the issue link. The other entries on this branch, and those on
  PR #2434 and PR #2435, already reference only their PR.

Signed-off-by: F.N. Claessen <felix@seita.nl>

Context:
- Review by @nhoening: PR #2434 now isolates the KPI window fix, so this PR
  should carry neither the changelog entry nor the code, nor its test.
- Almost right. What this PR genuinely needs is narrower than the fix: the
  advance must not reach storeEndDate or previousResult.end, because both
  are handed to the cache, which would then record a span a day wider than
  it holds. It does not need the advance gone.

Change:
- Restore getAssetKPIs to what main has, advance and all, so the fix and
  its user-visible effect belong wholly to PR #2434.
- Pass copies at both call sites, which changes no KPI value and keeps the
  chart's own dates out of reach. Once #2434 lands these are belt and
  braces, and the two branches merge either way.
- Drop the changelog entry and test_kpi_window_end_is_exclusive, which
  #2434 carries.
- Say why replay fetches around the cache rather than through it.

Signed-off-by: F.N. Claessen <felix@seita.nl>

…2433)

* ui/graphs: stop the KPI fetch from corrupting the chart's date range

Context:
- getAssetKPIs() advances the end date it is given by one day, to make the
  KPI window inclusive.
- On the asset page, it was handed the very Date objects that storeEndDate
  and previousResult.end hold, so after one date selection both were a day
  late. The exact-range short-circuit in fetchGraphDataAndKPIs then stopped
  matching, and embedAndLoad sliced a day too much off the cached data.
- The initial call additionally read storeStartDate/storeEndDate from the
  module body, which is evaluated before the DOMContentLoaded handler that
  assigns them (verified in headless Chrome), so on an asset with KPIs it
  threw on undefined and aborted the rest of the module.

Change:
- Pass copies to getAssetKPIs at both call sites.
- Derive the initial window from the template values rather than from the
  not-yet-assigned globals.

Signed-off-by: F.N. Claessen <felix@seita.nl>

* ui/graphs: fetch chart data through a single module

Context:
- Four call sites in graphs.html (initial load, sensors-to-show reload,
  replay, and date selection) each built the same /chart_data query string
  by hand and repeated the same response handling.
- That duplication is what makes a reuse cache awkward to add: it would
  have to be threaded through every call site separately.

Change:
- Add chart-data-source.js with buildChartDataUrl, fetchChartData and
  fetchChartAnnotations, and route all five fetches through it.
- Drop the now-unused decompressChartData import, the dead module-level
  queryStartDate/queryEndDate, and two parameters of fetchGraphDataAndKPIs
  that the caller no longer needs.
- No behaviour change: the generated URLs are unchanged.

Signed-off-by: F.N. Claessen <felix@seita.nl>

* ui/graphs: fetch only the newly selected days, not the whole window

Context:
- Issue #101: changing the selected time window re-queried the entire
  window, even when almost all of it was already loaded. Only an exactly
  identical selection was served from memory.
- Profiling a 5-sensor asset holding a year of 15-minute data: a request
  costs ~105 ms regardless of size, plus ~24 us per record. Re-fetching a
  year takes ~4.4 s and 14 MiB, of which ~93% is server time.

Change:
- Add chart-data-cache.js, which works out what a newly selected window
  adds to the loaded one and fetches only that.
- The date picker only yields whole nominal days, so the loaded window is
  always one contiguous range; interval arithmetic stays on Date objects
  so a 23- or 25-hour day across a DST transition stays correct.
- Merged records are de-duplicated, since an event straddling the seam is
  returned by both halves.
- A window fully inside the loaded one now needs no request at all.

Signed-off-by: F.N. Claessen <felix@seita.nl>

* data/tests: pin down that a chart data window can be fetched in parts

Context:
- The UI now fetches only the part of a newly selected window that it does
  not already hold, which assumes that [a, b) plus [b, c) equals [a, c).

Change:
- Assert that splitting a window loses no events and changes no values,
  for resolutions that divide a day and for one (7 minutes) that does not.
- Assert that the event straddling the seam is repeated rather than
  dropped, and that both halves agree on its value, which is what makes
  de-duplicating in the front end sufficient.

Signed-off-by: F.N. Claessen <felix@seita.nl>

* docs: changelog entries for the chart data reuse and the KPI date fix

Context:
- Both changes are user-visible: charts respond faster to a new date
  selection, and the KPI-related date corruption is a bugfix.

Change:
- Add one entry under New features and one under Bugfixes for v1.1.0.
- PR numbers are placeholders (XXXX) until the PR exists.

Signed-off-by: F.N. Claessen <felix@seita.nl>

* ui/graphs: keep the widest span loaded, so zooming back out is free

Context:
- The reuse introduced in the previous commit trimmed its records to the
  window on display, so narrowing the selection discarded everything
  outside it. Zooming into 7 days of a loaded 31-day window and back out
  then re-fetched the other 24 days in two requests.

Change:
- Hold the widest contiguous span fetched so far and clip only what is
  handed to the chart, so a narrowed selection and a return to the earlier
  span both cost nothing.
- The cache is bounded by the widest contiguous span browsed, which is
  what selecting that span in one go would have loaded anyway. Selecting a
  window that does not touch the cached span replaces it, so the cached
  span stays contiguous.
- Reset the cache in reloadChartData, where the sensors shown or the data
  itself may have changed and nothing held is still trustworthy.

Signed-off-by: F.N. Claessen <felix@seita.nl>

* docs: fill in the PR number in the changelog entries

Context:
- The entries were added before the PR existed, with XXXX placeholders.

Change:
- Point both entries at PR #2433.

Signed-off-by: F.N. Claessen <felix@seita.nl>

* ui/graphs: rename chart-data-source.js to chart-data-fetch.js

Context:
- Review feedback: "source" is reserved for belief sourcing in this repo,
  so naming a module after it is misleading.

Change:
- Rename the module and update its two importers.

Signed-off-by: F.N. Claessen <felix@seita.nl>

* ui/graphs: reuse only what a direct fetch would have returned

Context:
- Review feedback: clipping cached records by event_start does not match
  the API, which selects events *overlapping* the window
  (event_ends_after / event_starts_before). A 50-minute sensor lost its
  leading event whenever the window was narrowed, since that event starts
  before midnight and runs into the day.
- Investigating that surfaced a second, larger mismatch: the API anchors
  its resampling at the start of the window asked for, so a coarser sensor
  shown next to a 7-minute one comes back on shifted timestamps for a
  window offset by a fraction of the resolution. Those records cannot be
  reconciled with the ones already held.

Change:
- Clip on overlap rather than on event_start, and match instantaneous
  events inclusively on both edges, as the API does.
- Derive the resolution the events are actually spaced on: every sensor
  with a resolution is resampled to the finest one requested, while the
  response still reports each sensor's own.
- Refuse to reuse records for a window that is not on the same resampling
  grid, falling back to fetching the window whole. Whole-day selections of
  sensors whose resolution divides a day are always aligned, so this only
  bites the cases that were wrong before.

Signed-off-by: F.N. Claessen <felix@seita.nl>

* ui/graphs: seed the cache with the initially loaded window

Context:
- Review feedback: the cache was only ever filled by a date selection, so
  the first selection after a page load found it empty and re-fetched the
  whole newly selected range, even though the initial window was already
  in memory. The same applied after a reload triggered by a data change.

Change:
- Route the initial load and the post-reset reload through the cache, so
  the optimisation applies from the first date change onwards. Neither
  changes what is requested: an empty cache fetches the whole window.

Signed-off-by: F.N. Claessen <felix@seita.nl>

* data/tests: pin down the window semantics the chart cache relies on

Context:
- The front end reproduces a fetch from records it already holds, so it
  depends on three behaviours that were not covered.

Change:
- Assert that a window selects events overlapping it, not only events
  starting inside it.
- Assert that instantaneous events are included on both window edges.
- Assert that resampling is anchored at the requested window start, which
  is why the front end refuses to reuse records across such a shift.
- Reflow two docstrings to break only after punctuation, per the repo
  convention.

Signed-off-by: F.N. Claessen <felix@seita.nl>

* ui/graphs: treat touching windows as one contiguous span

Context:
- Review feedback: reuse required a strict overlap, so a selection stepped
  on by exactly its own width (start === cached.end) counted as disjoint
  and replaced the cache. Stepping back then re-fetched a window that had
  just been thrown away, which is the opposite of holding the widest span.

Change:
- Allow the boundaries to touch, so such a selection extends the cached
  span instead of replacing it. What gets fetched is unchanged: the new
  window is still entirely missing and is still fetched whole.
- Note in missingRanges that the half-open convention has one exception,
  instantaneous sensors, which the API matches inclusively on both edges.

Signed-off-by: F.N. Claessen <felix@seita.nl>

* ui/graphs: stop getAssetKPIs from mutating the window it is given

Context:
- Review feedback: passing defensive copies at both call sites left the
  trap in place, since the next caller has to know to do the same. That is
  what caused the date corruption fixed in 04d6b1b.

Change:
- Advance a copy of the end date inside getAssetKPIs, and drop the copies
  at the call sites, which can now pass the chart's own window dates.

Signed-off-by: F.N. Claessen <felix@seita.nl>

* ui/graphs: break the JavaScript comments only after punctuation

Context:
- The repo's line-break convention was written for Python, but it exists
  for stable review comments and text search, which applies just as much
  to the JavaScript comments added here.

Change:
- Reflow the JSDoc blocks and inline comments in chart-data-cache.js,
  chart-data-fetch.js and the graphs.html module, so that every physical
  line ends at a comma, semicolon, colon or period.

Signed-off-by: F.N. Claessen <felix@seita.nl>

* agents/docstrings: extend the line-break convention to JavaScript

Context:
- The convention only claimed to apply to Python, so JavaScript comments
  were outside it, even though the reasons for it (stable review comments
  and text search) do not depend on the language.

Change:
- Widen applyTo to .js and .html, retitle to "Docstrings and comments",
  and scope the RST/Click/doctest guidance as Python-specific.
- Add a JavaScript section covering JSDoc blocks and // comments, in .js
  files and in the script blocks of Jinja templates, with an example, and
  note that @param/@returns lines stay on one line however long.
- State that automated reviewers should report JavaScript comments that
  wrap mid-phrase, as they already do for Python docstrings.

Signed-off-by: F.N. Claessen <felix@seita.nl>

* agents/docstrings: match how the other instruction files scope themselves

Context:
- Review feedback: the comma-separated applyTo glob was unlike any other
  instruction file here, and a consumer reading it as one literal pattern
  would match nothing, silently disabling the instructions altogether.

Change:
- Use applyTo "**", as the other cross-language instruction files do. The
  headings already separate the Python-specific guidance from the
  JavaScript section, so the scoping does not need to live in the glob.

Signed-off-by: F.N. Claessen <felix@seita.nl>

* ui/graphs: require the options that the fetch helpers cannot work without

Context:
- Review feedback: the helpers defaulted their options object to {} and
  then dereferenced start and end regardless, so the default only served
  to postpone the failure and suggest the argument was optional.

Change:
- Drop the defaults, since every one of these helpers needs a window.

Signed-off-by: F.N. Claessen <felix@seita.nl>

* ui/graphs: stop the KPIs counting a day the chart does not show

Context:
- Review feedback: getAssetKPIs advanced its end date by a day to "make
  the end date inclusive", but both callers already hand it the chart's
  exclusive end, and the endpoint ends its own window before `end` too
  (_get_sensor_stats filters event_start < end).
- Every KPI therefore covered one day more than the chart beside it. On a
  seeded asset with one unit of energy per day, a three-day selection
  reported a total of four.

Change:
- Pass the chart's end date through unchanged.

Signed-off-by: F.N. Claessen <felix@seita.nl>

* api/v3_0/tests: pin down that the KPI window's end is exclusive

Context:
- The asset page derives the KPI window from the chart's, so the two have
  to agree on whether the end is part of the window. Nothing said so.

Change:
- Assert that a three-day window over one daily value per day totals
  three, not four.

Signed-off-by: F.N. Claessen <felix@seita.nl>

* docs: changelog entry for the KPI window fix

Context:
- KPI figures change for anyone using them, so this needs saying.

Change:
- Add a Bugfixes entry for v1.1.0.

Signed-off-by: F.N. Claessen <felix@seita.nl>

* ui/graphs: correct why the initial window is derived from the template

Context:
- Review feedback: the comment claimed this code runs in the module body,
  before the DOMContentLoaded handler assigns storeStartDate/storeEndDate.
  That is wrong. Checked against the parsed page: on the asset page the
  block sits inside that handler, so the globals are already assigned.
- The real reason not to read them is worse. The handler's closing brace
  sits inside a Jinja conditional, the sensor upload block, so the handler
  ends at that point only when it renders. On every other page it runs on
  to the end of the module. Whether this code is inside the handler
  therefore depends on the page, and deriving the window from the template
  values is what works either way.
- Consequently the claim that the chart failed to load on an asset page's
  first visit was wrong too: the globals were assigned by then. The date
  corruption that 04d6b1b also fixed was real and is unaffected.

Change:
- Replace the comment with the actual reason.
- Drop the incorrect half of the changelog entry.
- Tie the KPI window test to the requesting user's account, rather than to
  whichever account the database returns first.

Signed-off-by: F.N. Claessen <felix@seita.nl>

* ui/graphs: read the initial window from the globals already assigned

Context:
- Twice now I claimed this block was not inside the DOMContentLoaded
  handler: first that it ran in the module body, then that the handler's
  extent varied per page because its closing brace sat in a Jinja
  conditional. Both were inferred from indentation and both were wrong.
- Parsing the rendered pages settles it. The handler spans the same region
  on the asset page and on the sensor page, closing unconditionally at the
  end of the timezone check, and the initial window is inside it and after
  the assignment of storeStartDate/storeEndDate in every case.
- The brace that misled me closes the sensor upload click listener. It is
  written at four spaces where the listener is opened at eight, so it
  reads as the end of the handler.

Change:
- Use storeStartDate/storeEndDate, as main did, dropping the second copy
  of the window that was only introduced to work around a problem that
  does not exist.
- Indent the upload listener's closing brace to match its opening, so the
  next reader is not misled the same way.

Signed-off-by: F.N. Claessen <felix@seita.nl>

* docs: leave the KPI window entry to its own PR

Context:
- The KPI day-counting fix was split out into PR #2434, since it changes
  user-visible numbers while this PR is a performance change. Both
  branches carry the same code change and merge cleanly either way, but
  the changelog would have gained the line twice.

Change:
- Drop the entry here. The date-corruption entry stays, as that fix is
  needed by the cache in this PR.

Signed-off-by: F.N. Claessen <felix@seita.nl>

* ui/graphs: keep the cache consistent when selections overlap

Context:
- Date selections are not serialised and their requests are not aborted,
  so two can be in flight at once. The merge read what was held *after*
  awaiting, by which time another selection may have replaced it.
- Selecting [1, 7) and then [20, 25), with the second answered first, left
  the cache claiming [1, 25) while holding only the two ends. Selecting
  [10, 12) afterwards was then served from that gap: an empty chart, with
  no request made. The widening selection itself also returned 2 of its 6
  days, since it merged against the unrelated window.

Change:
- Snapshot what is held on entry and merge against that snapshot, so a
  result's span and its records always describe the same thing.
- Return the window this call assembled, rather than whatever is held by
  the time it finishes. Whichever selection finishes last decides what is
  kept; both spans are self-consistent, so the worst case is a later
  selection re-fetching.

Signed-off-by: F.N. Claessen <felix@seita.nl>

* ui/graphs: ignore the answer to a window no longer on screen

Context:
- Review feedback: the picker's selected handler starts its requests
  without aborting any still in flight, and whichever settles last draws
  itself and becomes previousResult. A slow earlier selection answering
  after a quick later one therefore put the older range on screen, while
  the picker and the URL named the newer one.
- The cache fix in 9928c43 addressed a different race, inside the cache.
  It kept what is held self-consistent, but said nothing about which
  answer the page draws.

Change:
- Count how often the shown window changes, claim that count when a
  selection starts, and drop the result if the count has moved on.
- Bump the same count when reloadChartData runs, since a reload for
  changed data supersedes any selection still in flight.

Signed-off-by: F.N. Claessen <felix@seita.nl>

* ui/graphs: guard the reload against being overtaken too

Context:
- Review feedback: 1b95e9c had reloadChartData bump the shown-window
  count so that a selection in flight could not overwrite it, but the
  reload never checked the count itself. A range selected while a reload
  was running could therefore render first, and the reload could then
  finish and draw the window the user had already moved away from.
- The guard was written in one direction only.

Change:
- Have the reload claim a count as the selection handler does, and drop
  its result if a window has been shown since.

Signed-off-by: F.N. Claessen <felix@seita.nl>

* ui/graphs: give the date picker the range it is meant to open on

Context:
- The initial load declared `var sessionStart` and `var sessionEnd` inside
  the DOMContentLoaded handler, far below the picker's creation. Being
  `var`, they were hoisted to the top of that handler and shadowed the
  module-level values assigned earlier.
- So createPicker(sessionStart, sessionEnd, ...) and, on simulation
  servers, computeSimulationRanges(...) both received `undefined` rather
  than the session's window. Confirmed by parsing the rendered page, which
  puts the declaration at line 341 and the use at line 217 within one
  handler spanning 170 to 434, and by running the same shape in a browser.

Change:
- Drop the two shadowing declarations and build the dates where they are
  used, so the module-level values reach the picker.

Signed-off-by: F.N. Claessen <felix@seita.nl>

* ui/graphs: guard the first load against being overtaken as well

Context:
- Review feedback: the picker is created before the initial load starts,
  and that load can take seconds on a wide window, so a range selected
  while it runs would render first and then be overwritten when the first
  load resolved.
- That is the third async path onto the chart, after the selection handler
  and the reload, and the only one still unguarded.

Change:
- Claim a count for the initial load and draw its result only if no window
  has been shown since.

Signed-off-by: F.N. Claessen <felix@seita.nl>

* docs: reference only the PR in the changelog entry

Context:
- Review feedback: the entry linked both the PR and the issue it closes.

Change:
- Drop the issue link. The other entries on this branch, and those on
  PR #2434 and PR #2435, already reference only their PR.

Signed-off-by: F.N. Claessen <felix@seita.nl>

* ui/graphs: drop the last comment claiming getAssetKPIs mutates its argument

Context:
- Found while adversarially reviewing PR #2434: this branch corrected the
  inline comment about the fastChartWindow snapshot but left the block
  comment above the declaration still giving the old reason, that
  getAssetKPIs bumps storeEndDate by a day. It does not, since bc6d5c1.

Change:
- Give the snapshot its real reason, matching the wording on PR #2434 so
  the two branches stay identical here.

Signed-off-by: F.N. Claessen <felix@seita.nl>

* ui/graphs: hand the KPI window fix to its own PR

Context:
- Review by @nhoening: PR #2434 now isolates the KPI window fix, so this PR
  should carry neither the changelog entry nor the code, nor its test.
- Almost right. What this PR genuinely needs is narrower than the fix: the
  advance must not reach storeEndDate or previousResult.end, because both
  are handed to the cache, which would then record a span a day wider than
  it holds. It does not need the advance gone.

Change:
- Restore getAssetKPIs to what main has, advance and all, so the fix and
  its user-visible effect belong wholly to PR #2434.
- Pass copies at both call sites, which changes no KPI value and keeps the
  chart's own dates out of reach. Once #2434 lands these are belt and
  braces, and the two branches merge either way.
- Drop the changelog entry and test_kpi_window_end_is_exclusive, which
  #2434 carries.
- Say why replay fetches around the cache rather than through it.

Signed-off-by: F.N. Claessen <felix@seita.nl>

* ui/graphs: stop reusing records indefinitely

Context:
- Review by @nhoening: the cache had no age limit. Data written elsewhere,
  by a report or another user, raises no event in this tab, so a window
  left open kept answering from what was true when it was opened. Changing
  the date range used to fetch, and so used to show such data; with the
  cache it no longer did.

Change:
- Hold records for five minutes. Long enough that stepping or widening a
  selection is still answered from memory, short enough that a page left
  open picks up data written elsewhere before long.
- Extending a span keeps its original age, so it cannot be kept alive
  indefinitely by being added to.
- The limit is a parameter of the cache, so tests can age it in
  milliseconds rather than waiting.

Signed-off-by: F.N. Claessen <felix@seita.nl>

---------

Signed-off-by: F.N. Claessen <felix@seita.nl>
Signed-off-by: Nicolas Höning <nicolas@seita.nl>
Co-authored-by: Nicolas Höning <nicolas@seita.nl>

* ui/tests: run the JavaScript modules in a browser, from pytest

Context:
- The modules under ui/static/js had no tests, and the only way we had
  checked them was by hand. They are plain ES modules, so they can be
  exercised directly, but ES imports do not work over file://.
- A Node.js toolchain would be a heavy addition for ~5k lines of
  JavaScript, and would need its own CI job.

Change:
- Add a fixture that serves the modules over HTTP and runs a page of
  assertions in headless Chrome, reporting the results through pytest.
  Tests pass a snippet of JavaScript and assert on the checks it records.
- Allow a test to place the browser in a chosen timezone, so that
  behaviour around daylight saving is not tied to the machine.
- Add selenium to the test dependency group, which the runtime image does
  not install. The tests skip when selenium or Chrome is missing.

Signed-off-by: F.N. Claessen <felix@seita.nl>

* ui/tests: cover the date, data and chart-data helpers

Change:
- Test toIsoStringWithOffset, subtract and countDSTTransitions, the last
  under two fixed timezones, one with daylight saving and one without.
- Test getUniqueValues and convertToCSV.
- Test decompressChartData, including the pass-through of data already in
  the old format and the conversion of seconds-valued sensors to dates.

Signed-off-by: F.N. Claessen <felix@seita.nl>

* ui/static: fix two bugs the new JavaScript tests found

Context:
- toIsoStringWithOffset appended the local UTC offset to date.toISOString(),
  which is UTC, without moving the clock time. The result named an instant
  wrong by exactly that offset. Its only caller sends the KPI window to the
  API, so KPIs could cover the wrong days, by a whole day west of UTC.
- getUniqueValues ended its loop at the first falsy entry, and tested for
  values already seen with `in`, which consults the prototype chain, so a
  source named "constructor" or "toString" was silently dropped.

Change:
- Write the local clock time, then append the offset.
- Iterate by index, track what has been seen in a Set, and guard the nested
  lookup against a missing record.

Signed-off-by: F.N. Claessen <felix@seita.nl>

* docs: changelog entries for the JavaScript tests and the KPI time range fix

Context:
- One is infrastructure for plugin developers and hosts, the other is a
  user-visible fix.

Change:
- Add both to v1.1.0. PR numbers are placeholders until the PR exists.

Signed-off-by: F.N. Claessen <felix@seita.nl>

* docs: fill in the PR number in the changelog entries

Context:
- The entries were added before the PR existed, with XXXX placeholders.

Change:
- Point both at PR #2435.

Signed-off-by: F.N. Claessen <felix@seita.nl>

* ui/static: stop counting a record with no source as a source

Context:
- Review feedback on getUniqueValues: a record that lacks the key yields
  undefined, which then landed in the results.
- Its only caller, checkSourceMasking, counts distinct source ids to decide
  whether to warn that data is being masked, so one record without a source
  made it warn about masking that was not happening.
- This predates the null-entry fix in this PR: a record carrying no source
  at all already contributed an undefined.

Change:
- Skip values that are absent, and assert that a record without a source
  contributes nothing.

Signed-off-by: F.N. Claessen <felix@seita.nl>

* build: lock the selenium test dependency

Context:
- CI installs from uv.lock with --frozen, so adding selenium to the test
  group without relocking failed the pre-commit check and the image build.
- Locking with an older uv rewrote the file to an earlier revision, so this
  was done with 0.10.9, the version CI pins.

Change:
- Add selenium and its eight dependencies. Nothing else moved: no package
  was removed and no existing version changed.
- Apply black to the new test fixture.

Signed-off-by: F.N. Claessen <felix@seita.nl>

* ui/tests: format with the black version this repo pins

Context:
- CI failed on formatting the new test files. The repo pins black 26.3.1,
  which hugs multiline strings; the black in my environment was 25.1.0,
  which leaves them wrapped, so it reported the files as clean.

Change:
- Reformat with 26.3.1.

Signed-off-by: F.N. Claessen <felix@seita.nl>

* ui/tests: break the run() docstring only after punctuation

Context:
- Review feedback: the sentence wrapped after "daylight saving", against
  the repo convention, which PR #2433 has just extended to cover
  JavaScript as well as Python.

Change:
- Reflow so each line ends at a comma or a period.

Signed-off-by: F.N. Claessen <felix@seita.nl>

* ui/static: say in the JSDoc that the clock time written is the local one

Context:
- Adversarial review of PR #2434: the example did not say which clock the
  components come from, which is exactly what the fix changed.

Change:
- State it, and keep the file identical to the copy on PR #2434.

Signed-off-by: F.N. Claessen <felix@seita.nl>

---------

Signed-off-by: F.N. Claessen <felix@seita.nl>

The v1.0.1 patch release backported #2434, #2461, #2465, #2473, #2475
(partial - only the ad98460751d9 migration fix), #2479, #2480, #2482,
#2499, #2502 and #2507 from this history to the 1.0.x branch. Move their
changelog bullets out of the v1.1.0 section into a new v1.0.1 section, so
the same fix is not listed as unreleased once 1.0.1 ships; the CLI
changelog gets a matching 'since v1.0.1' section. The API change log
keeps its own independent v3.0-NN numbering and is untouched.

Signed-off-by: F.N. Claessen <claessen@seita.nl>